黑色好看版 - 傳送門

正文開始

上一篇文章中咱們學習完了 CDN 的相關知識以後，接下來這篇文章，我們將要將上一篇所學的來改善咱們以下兩篇文章可動版的架構。

使用 CDN 來調整可動版的架構

30-20之如何建立像 KKTV 一樣的點播功能呢 ?
30-21之如何建立的像 17 一樣的直播功能呢 ?

點播

直播

本篇文章會分成以下幾個章節：

• 可動版本的問題。
• 點播的架構改善版本。
• 直播的架構改善版本。

可動版本的問題

在筆者這篇文章中『30-22之點播與直播可動版問題探討』，我們探討了可動版有以下的問題：

1. 人多時連線數限制問題。
2. 人多時頻寬問題。
3. 人多時效能消耗問題。
4. 遠距離看片卡頓的問題。

基本上 1、3 我們可以用傳統的方法(加機器)來解決，而 2、4 就無法使用加機器來進行解決，因為以 2 的頻寬問題，就算你加了在多的機器，如果你在出去的網路還是在同一條，那頻寬還是沒加大，問題還是沒解決。而 4 的話就更不用說，只能讓使用者離機器更近一點才能解決。

點播架構的改善版本

基本上點播的架構會改成如下圖，它會將 CDN 加上去，而這樣就可幫助我們解決頻寬與距離看片卡頓的問題。

先來說說頻寬的部份， CDN 基本上分散在不同的地方，這也代表這基本上它們的頻寬是各別獨立的，所以不太會發生搶頻寬的問題，而另一點距離的問題，由於大部份的 CDN 都會搭配使用智能 DNS 來幫助找到最近的 CDN，因此可以解決因為離影片來源太遠，而容易造成封包遺失與封包順序不一致問題。

而且用了 CDN 事實上還有一個好處，那就是可以保證接近 100 的機率可以看片，你想想如果是自已建的一台 Media Server 來提供看片，如果它倒了，不就不能看片了，而有 CDN 就可以自動的轉到另一個臨近的 CDN 來取得資料。

接下來說說它的運行流程，基本上如下 (以 HLS 拉流為範例)：

1. Media Server 收到新的影片檔，然後它會將他進行切片，分成一小個一小個檔案 .ts。
2. 接下來會分發到各 CDN 上。
3. 有個用戶發送 Http 請求到智能 DNS 會給予最近的 CDN 位置。
4. 用戶在發送請求給 CDN 取得影片，CDN 開始將一小段一小段 .ts 傳送給用戶。

直播架構的改善版本

首先我們先看加了 CDN 的第一種的改善版如下圖。這種架構基本上一樣可以解決掉頻寬與遠距離觀看會卡頓的問題。

它的運行流程如下：

1. 直播主推送 RTMP 到 Media Server。
2. Media Server 將 RMTP 依據所需支援的協議，切分成小檔案 (ex. HLS 的 .ts)
3. Media Server 推送到 CDN。
4. 聽眾使用拉流 (ex. HLS、HTTP-FLV、Dash、RTMP) 來觀看直播主。

上面這個版本有啥問題嗎 ?

如果這是個非互動性要求的直播 (ex. 運動賽事直播) 的話，那問題不大。

但如果是要求互動性的直播，那就有問題了，因為它的延遲會比沒有使用 CDN 還高，也就說沒使用 CDN 時直播主說話後要 5 秒鐘才能聽的到的話，那用了 CDN 可能就要 10 秒，原因如下圖，因為它要多傳輸不少東西。

因此後來有人就提出直接將直播主的聲音丟到 CDN，然後由 CDN 來處理切分這些事情，架構圖與執行流程如下。但是相對的此架構的成本一定會比上述的還高，因為 CDN 要幫你多做不少事情。

1. 直播主推送 RTMP 到離它最近的 CDN。
2. CDN 幫你依據所需支援的協議，切分成小檔案。
3. 聽眾使用拉流 (ex. HLS、HTTP-FLV、Dash、RTMP) 來去最近的 CDN 觀看直播主。
4. 離聽眾最近的 CDN 會使用拉流來將直播主所在的 CDN 進行畫面拉去。

結論

基本上以上的點播與直播的改善版本，應該就是大部份雛形，然後你只要記好，在直播與點播的應用中，沒有 CDN 應該是無法做起來的，所以入深入的理解 CDN 的原因與理解各家 CDN 的應用，相信可以幫助你做出各優質的點播與直播的應用。

接下來下一篇文章，我們就要來研究看看互動直動的一些挑戰。

參考

• 首次披露：快手是如何做到百万观众同场看直播仍能秒开且不卡顿的？
• 视频直播| 基础原理篇
• 直播CDN相關技術